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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in respect 
of ETSI standards", which is available free of charge from the ETSI Secretariat. Latest updates are available on the 
ETSI Web server (http://www.etsi.fr/ipr or http://www.etsi.org/ipr). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in SR 000 314 (or the updates on the ETSI Web server) 
which are, or may be, or may become, essential to the present document. 



Foreword 



This ETSI Technical Specification has been produced by Special Mobile Group (SMG) of the European 
Telecommunications Standards Institute (ETSI). 

This TS defines the Cell Broadcast short message service (CBS). It defines the primitives over the Cell Broadcast 
Centre - Base Station System (CBC-BSS) interface and the message formats over the Base Station System - Mobile 
Station (BSS-MS) interface for Teleservice 23 within the digital cellular telecommunications system (Phase 2+). 

The contents of this TS are subject to continuing work within SMG and may change following formal SMG approval. 
Should SMG modify the contents of this TS it will then be republished by ETSI with an identifying change of release 
date and an increase in version number as follows: 

Version 6.x.y 

where: 

6 GSM Phase 2+ Release 1997 

X the second digit is incremented for all other types of changes, i.e. technical enhancements, corrections, 
updates, etc. 

y the third digit is incremented when editorial only changes have been incorporated in the specification. 
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1 Scope 



This Technical Specification describes the Cell Broadcast short message service (CBS). It defines the primitives over 
the Cell Broadcast Centre - Base Station System (CBC-BSS) interface and the message formats over the Base Station 
System - Mobile Station (BSS-MS) interface for Teleservice 23 as specified in GSM 02.03 [2]. 

1.1 Normative references 

References may be made to: 

a) specific versions of publications (identified by date of publication, edition number, version number, etc.), in 
which case, subsequent revisions to the referenced document do not apply; or 

b) all versions up to and including the identified version (identified by "up to and including" before the version 
identity); or 

c) all versions subsequent to and including the identified version (identified by "onwards" following the version 
identity); or 

d) publications without mention of a specific version, in which case the latest version applies. 

A non-specific reference to an ETS shall also be taken to refer to later versions published as an EN with the same 
number. 

[I] GSM 01.04: "Digital cellular telecommunication system (Phase 2+); Abbreviations and acronyms". 

[2] GSM 02.03: "Digital cellular telecommunication system (Phase 2+); Teleservices supported by a 

GSM Public Land Mobile Network (PLMN)". 

[3] GSM 03.38: "Digital cellular telecommunication system (Phase 2+);"Alphabets and language- 

specific information". 

[4] GSM 03.40: "Digital cellular telecommunication system (Phase 2+); Technical realization of the 

Short Message Service (SMS) Point to Point (PP)". 

[5] GSM 03.47: "Digital cellular telecommunication system (Phase 2+); Example protocol stacks for 

interconnecting Service Centre(s) (SC) and Mobile-services Switching Centre(s) (MSC)". 

[6] GSM 03.49: "Digital cellular telecommunication system (Phase 2+); Example protocol stacks for 

interconnecting Cell Broadcast Centre (CBC) and Mobile-services Switching Centre (MSC)". 

[7] GSM 04.12: "Digital cellular telecommunication system (Phase 2+); Short Message Service Cell 

Broadcast (SMSCB) support on the mobile radio interface". 

[8] GSM 05.02: "Digital cellular telecommunication system (Phase 2+); Multiplexing and multiple 

access on the radio path". 

[9] GSM 07.05: "Digital cellular telecommunication system (Phase 2+); Use of Data Terminal 

Equipment - Data Circuit terminating Equipment (DTE - DCE) interface for Short Message 
Service (SMS) and Cell Broadcast Service (CBS)". 

[10] GSM 08.52: "Digital cellular telecommunication system (Phase 2+); Base Station Controller - 

Base Transceiver Station (BSC - BTS) interface Interface principles". 

[II] GSM 08.58: "Digital cellular telecommunication system (Phase 2+); Base Station Controller - 
Base Transceiver Station (BSC - BTS) interface Layer 3 specification". 

[12] CCITT Recommendation X.210: "Open systems interconnection layer service definition 

conventions". 
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1 .2 Abbreviations 

Abbreviations used in this TS are listed in GSM 01.04 [1]. 



General description 



The CBS service is analogous to the Teletex service offered on television, in that like Teletex, it permits a number of 
unacknowledged general messages to be broadcast to all receivers within a particular region. CBS messages are 
broadcast to defined geographical areas known as cell broadcast areas. These areas may comprise of one or more cells, 
or may comprise the entire PLMN. Individual CBS messages will be assigned their own geographical coverage areas by 
mutual agreement between the information provider and the PLMN operator. CBS messages may originate from a 
number of Cell Broadcast Entities (CBEs), which are connected to the Cell Broadcast Centre. CBS messages are then 
sent from the CBC to the BTSs, in accordance with the CBS's coverage requirements. 

The CBS message comprises of 82 octets, which, using the default character set, equates to 93 characters. Up to 15 of 
these messages (pages) may be concatenated to form a macromessage. Each page of such macromessages will have the 
same message identifier (indicating the source of the message), and the same serial number. Using this information, the 
MS is able to identify and ignore 
re-broadcasts of already received messages. 

CBS messages are broadcast cyclically by the BTS at a frequency and for a duration specified by the information 
provider. The frequency at which messages are repeatedly transmitted will be dependent on the information that they 
contain; for example, it is likely that dynamic information such as road traffic information, will require more frequent 
transmission than weather information. The repetition period will also be affected by the desire for messages to be 
received by high speed mobiles which rapidly traverse cells. All suitably equipped mobiles within the catchment area of 
the transmitting BTS will be able to receive the broadcast messages, provided that they are switched on and in the idle 
state. 

CBS messages may be broadcast on two different cell broadcast channels, which are characterized by different QoS. A 
MS is always able to read the basic channel (see [8]). The reading of the extended channel may collide with other tasks 
of the MS. Therefore the probability of receiving a CBS message on the extended channel is smaller than on the basic 
channel. The reading of the extended channel for MSs is optional. The scheduling on the channels will be done 
independently. 

To permit mobiles to selectively display only those messages required by the MS user, CBS messages are assigned a 
message class which categorises the type of information that they contain and the language in which the message has 
been compiled. Through the use of appropriate MMI, the user is then able to ignore message types that he does not wish 
to receive, e.g. advertising information or messages in an unfamiliar language. 



3 Network Architecture 

The basic network structure of CBS is depicted by figure 1. 
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Figure 1 

message transfer on link 1 is outside the scope of GSM Specifications; 

message transfer on link 2 is described in subclause 9. 1; 

message transfer on link 3 is described in GSM 08.58; 

message transfer on link 4 is described in GSM 04. 12 and the timing of messages transferred on link 4 is 
described in GSM 05.02. 



CBE Functionality 



The functionality of the CBE is outside of the scope of GSM Specifications; however it is assumed that the CBE is 
responsible for all aspects of formatting CBS, including the splitting of a CBS message into a number of pages. 



CBC Functionality 



As the CBC (and any originating point for cell broadcast short messages) is regarded as a node outside the PLMN, only 
the requirements placed upon the CBC by CBS functionality are specified by this specification. 

The CBC may be connected to several BSCs. The CBC may be connected to several CBEs. The CBC shall be 
responsible for the management of cell broadcast short messages including: 

allocation of serial numbers; 

modifying or deleting messages held by the BSC; 

initiating broadcast by sending fixed length cell broadcast short messages to a BSC for each language provided 
by the cell, and where necessary padding the message with the appropriate character to a length of 82 octets; 

determining the set of cells/BTSs to which a message should be broadcast, and indicating within the Serial 
Number the geographical scope of each message; 

determining the time at which a message should commence being broadcast; 

determining the time at which a message should cease being broadcast and subsequently instructing each BSC to 
cease broadcast of the message; 

determining the period at which broadcast of the message should be repeated; 
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determining the cell broadcast channel, on which the message should be broadcast. 

To work efficiently on the interfaces, the BSC - which is normally controlling more than one cell of a broadcast area - 
should be used as a concentrator as far as CB message handling is concerned. Hence, the CBC should work on lists of 
cells when issuing CB related requests towards the BSC. 



BSC Functionality 



The BSC shall interface to only one CBC. A BSC may interface to several BTSs as indicated by GSM 08.52. The BSC 
shall be responsible for: 

interpretation of commands from the CBC; 

- storage of cell broadcast messages; 

scheduling of cell broadcast messages on the CBCH; 

- providing an indication to the CBC when the desired repetition period cannot be achieved; 

- providing to the CBC acknowledgement of successful execution of commands received from the CBC; 

- reporting to the CBC failure when a command received from the CBC is not understood or cannot be executed; 

- routing cell broadcast messages to the appropriate BTSs; 

- transferring CBS information to each appropriate BTS via a sequence of 4 SMS BROADCAST REQUEST 
messages or 1 SMS BROADCAST COMMAND message (see GSM 08.58), indicating the channel which shall 
be used. 

optionally generating Schedule Messages, indicating the intended schedule of transmissions (see GSM 04. 12); 

optionally receiving CBCH Load Indication messages and reacting by broadcasting a burst of scheduled SMSCB 
messages or by suspending the broadcast for a period indicated by BTS (see GSM 08.58); 

To work efficiently on the interfaces, the BSC should forward CB related messages to the CBC using cell lists as far as 
applicable. 



BTS Functionality 



The BTS is responsible for conveying CBS information received via SMS BROADCAST REQUEST or SMS 
BROADCAST COMMAND messages over the radio path to the MS. 

optionally generating CBCH Load Indication messages, indicating an underflow or overflow situation on the 
CBCH (see GSM 08.58). 



8 MS Functionality 



The MS is responsible for recombination of the blocks received via the radio path to reconstitute the cell broadcast short 
message. The precise method of display of cell broadcast short messages is outside the scope of GSM Specifications, 
however it is assumed that an MS will: 

discard sequences transferred via the radio path (see GSM 04.12) which do not consist of consecutive blocks; 

have the ability to discard CBS information which is not in a suitable data coding scheme; 

- have the ability to discard a message which has a message identifier indicating that it is of subject matter which is 
not of interest to the MS; 
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- have the abihty to ignore repeat broadcasts of messages already received (message has not changed since it was 
last broadcast i.e. sequence number has not changed within the message's indicated geographical area); 

have the ability to transfer a message via the R interface when the R interface is supported; 

optionally enter SMSCB DRX mode based upon received Schedule Messages (see GSM 04.12); 

optionally skip reception of the remaining block(s) of a cell broadcast message which do(es) not contain cell 
broadcast information (see GSM 04.12); 

- optionally read the extended channel. 

9 Protocols and Protocol Architecture 

Commands interpreted by the BSC will resuh in a sequence of 4 SMS BROADCAST REQUEST messages or 1 SMS 
BROADCAST COMMAND message being sent to a BTS, which in turn result in a sequence of 4 messages being 
transferred via the BTS-MS interface (see GSM 04.12). 

With the SMS BROADCAST REQUEST mode of operation, the 88 octet fixed length CBS page which is specified in 
Section 9.3 is split into four 22 octet blocks which are carried in SMS BROADCAST REQUEST messages as follows: 

octets 1-22 are transferred in the l" SMS BROADCAST REQUEST 

with a sequence number (see GSM 04.12) indicating first block 

octets 23-44 are transferred in the 2"'' SMS BROADCAST REQUEST 

with a sequence number (see GSM 04.12) indicating second block 

octets 45-66 are transferred in the 3"* SMS BROADCAST REQUEST 

with a sequence number (see GSM 04. 12) indicating third block 

octets 67-88 are transferred in the 4* SMS BROADCAST REQUEST 

with a sequence number (see GSM 04.12) indicating fourth block. 

Figure 2 illustrates the protocol architecture and the scope of the various GSM Specifications for the SMS 
BROADCAST REQUEST mode of operation. 
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Figure 2 

With the SMS BROADCAST COMMAND mode of operation, the BSC sends to the BTS in one single message the 1 
octet fixed length CBS page. The BTS then splits the page into four 22 octet blocks, adds the sequence number (see 
GSM 04.12) and transmits the four resulting blocks on the air. 

Figure 3 illustrates the protocol architecture and the scope of the various GSM Specifications for the SMS 
BROADCAST COMMAND mode of operation. 
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9.1 



CBC-BSC Primitives 



The term primitive is used to indicate "an abstract, implementation independent interaction between a service user and a 
service provider" (see CCITT X.210). For the CBC-BSC interface, the service provider would be the protocol 
interconnecting CBC and BSC. A Primitive may therefore be viewed as an abstract, implementation independent 
request/indication or response/confirm interaction between the service user (CBC or BSC) and the service provider 
(protocol). A set of primitives for use between the CBC and BSC is specified appropriate to the functionality assigned to 
the CBC and BSC in Sections 5 and 6. In order to allow future extensions to the primitives, where possible a primitive 
shall not be rejected because a parameter is not recognised; the recipient shall ignore the parameter in question and 
process the remainder of the primitive's parameters as usual. No mandatory protocol between the CBC and the BSC is 
specified by GSM, this is a matter of agreement between CBC and PLMN operators. GSM 03.49 (see also annex A of 
this TS) provides example protocol stacks using the primitives defined as follows. 

NOTE: In the following definitions, M indicates "mandatory parameter" and O indicates "optional parameter". 



9.1 .1 Identification of a message 



Within a CBC-BSC interface, a message is uniquely identified by the quartet (message_identifier, serial_number. Cell 
Identifier, Channel Indicator). This means that even when two messages have the same semantic containts (for example 
the same weather forecast) but in different languages or coding schemes, they are considered as different and must 
therefore be identified by a different quartet. 

The serial number is managed cyclically and therefore this does not prevent the re-use of the same quartet for a different 
message when the serial number have been incremented a sufficient number of times. How to manage the ambiguity is 
described subsequently. 

This unique identification of a message across the CBC-BSC interface is used in all the primitives defined hereafter. 
This means that the quartet will be implicitly or explicitly present in every interface primitive which applies to a given 
message. 
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This unique quartet will be referred in the rest of the document as the « message reference ». 

9.1.2 WRITE-REPLACE Request/Indication 



PARAMETER 


REFERENCE 


PRESENCE 


Message-Identifier 


9.2.1 


M 


Old-Serial-Number 


9.2.2 





New-Serial-Number 


9.2.3 


M 


Cell-List 


9.2.5.1 


M 


Channel Indicator 


9.2.6 





Category 


9.2.7 





Repetition-Period 


9.2.8 


M 


No-of-Broadcasts-Requested 


9.2.9 


M 


Number-of-Pages 


9.2.4 


M 


Data Coding Scheme 


9.2.18 


M 


CBS-Message-Information-Page 1 


9.2.19 


M 


CBS-Message-Information-Length 1 


9.2.20 


M 


CBS-Message-Information-Page 2 


9.2.19 





CBS-Message-Information-Length 2 


9.2.20 





CBS-Message-Information-Page n 


9.2.19 





CBS-Message-Information-Length n 


9.2.20 






This primitive is sent by the CBC to the BSC. As this primitive can be used either to broadcast a new message or replace 
a message already broadcast, the CBC will use the presence and content of the Old-Serial-Number and New-Serial- 
Number fields in this primitive to instruct the BSC as follows:- 

Old-Serial-Number not present/New-Serial-Number present 

This is a write request which will be interpreted by the BSC as an instruction to broadcast a new message in all 
the cells of the Cell list and on the channel derived by the Channel Indicator (see the section on parameters that 
describes the implicit value of the Channel Indicator when not present in the message). The following table 
identifies the BSC's behaviour: 



Success/Failure of write 
request 


BSC behaviour 


Success 


The BSC completes the following parameters to be returned in the Report 
PDU: 

• a '0' value is entered in the number of broadcasts completed list for 
the cell 

• no entry is made in the failure list for the cell 


Failure 


The BSC completes the following parameters to be returned in the Report 
PDU: 

• no entry is made in the number of broadcasts completed Ust for the 
cell 

• an entry is made in the failure list for the new message identifying the 
failure cause for the cell 



The BSC will build as many message references as the number of cells in the list. These message references will 
be used in particular in the subsequent primitives. 

When a message reference is already known by the BSC for certain cells in the list (even if the Update field of 
the Serial-Number is different), the primitive will be rejected with the cause « message reference already used ». 
The list of cells where the message reference is not valid will be provided in the REPORT message. No entry 
will be made in the number of broadcasts completed parameter. 
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Old-Serial-Number present/New-Serial-Number present 

This is a replace request which will be interpreted by the BSC as a kill request for the message with the old serial 
number, followed by a write request for the message with the new serial number. The handling of the new serial 
number in the write part of this request, is as described above in the write request where no Old-Serial-Number is 
supplied. These two kill and write requests are executed sequentially. If the kill request is unsuccessful, the 
BSC does not proceed to execute the write request. The kill request will stop broadcast of, and cause all 
information currently associated with the combination of message identifier, old serial number, Channel Indicator 
and the list of cells in the Cell list to be deleted from the cells in the BSC (i.e. for all cells provided in the Cell- 
List parameter). If the kill request is successful, the subsequent write request information conveyed in the 
primitive replaces the killed message. The following table identifies the BSC's behaviour: 



Success/Failure of kill request 


BSC behaviour 


Success 


The BSC proceeds to execute the write request: 

• Write successful: the BSC completes the following parameters to be 
returned in the Report PDU: 

• an entry is made in the number of broadcasts completed list for 
the cell 

• no entry is made in the failure list for the cell 

• Write unsuccessful: the BSC completes the following parameters to be 
returned in the Report PDU: 

• an entry is made in the number of broadcasts completed list for 
the cell 

• an entry is made in the failure list for the new message 
identifying the failure cause for the cell 


Failure 


The BSC does not proceed to execute the write request, and completes the 
following parameters to be returned in the Report PDU: 

• no entry is made in the number of completed broadcasts list 

• an entry is made for the old message in the failure Ust identifying the 
failure cause for the cell 



All cells which should perform the broadcasting are mentioned in the Cell-List parameter. 

The broadcast of the referenced message in the cells which are not mentioned in the Cell-List remains unaffected. 

If no category is present, the default category is interpreted by the BSC, see the parameter section. 

This primitive is responded by a REPORT or REJECT primitive. 

NOTE: in the case of multipage messages, the individual pages are considered as independent by the BSC 
scheduling algorithm. 



9.1.3 KILL Request/Indication 



PARAMETER 


REFERENCE 


PRESENCE 


Message-Identifier 


9.2.1 


M 


Old-Serial-Number 


9.2.2 


M 


Cell-List 


9.2.5.1 


M 


Channel Indicator 


9.2.6 
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This primitive is sent by the CBC to the BSC. The CBC will use this primitive to kill the message indicated by the 
combination of message identifier, serial number, Channel Indicator and the cells indicated in the Cell-List of this KILL 
request, i.e. the primitive will halt broadcast of the message in the indicated cells and remove any knowledge of the 
message from the BSC for these cells. The broadcast of the referenced message in the cells which are not mentioned in 
the Cell-List remains unaffected. This primitive is responded with a REPORT or REJECT primitive. 



9.1.4 REPORT Response/Confirm 



PARAMETER 


REFERENCE 


PRESENCE 


Message-Identifier 


9.2.1 


M 


Serial-Number 


9.2.2 


M 


Channel Indicator 


9.2.6 





No-of-Broadcasts-Completed-List 


9.2.10 





Failure-List 


9.2.14 






This primitive will be sent by the BSC to the CBC in response to WRITE-REPLACE and KILL primitives. The Serial- 
Number field will contain the old serial number if this primitive is sent in response to a KILL primitive, and the new 
serial number if the primitive is sent in response to a WRITE-REPLACE primitive. 

The No-of-Broadcasts-Completed-List if present, may contain for each cell the number of broadcasts of the (replaced or 
killed) CB message with the old message reference sent to this particular cell for broadcast. The serial number 
information element in the case of a WRITE-REPLACE does not refer to the message for which the number of 
broadcasts completed information is supplied. The Failure-List if present, may contain those cells which were present in 
the related WRITE-REPLACE or KILL primitive and failed the requested operation. 

9.1 .5 STATUS-CBCH-QUERY Request/Indication 



PARAMETER 


REFERENCE 


PRESENCE 


Cell-List 
Channel Indicator 


9.2.5.1 
9.2.6 


M 




This primitive is sent by the CBC to the BSC in order to obtain the current loading of the CBCH of particular cells 
referenced in the Cell-List parameter. This primitive is responded by a STATUS-CBCH-QUERY Response/Confirm or 
a REJECT primitive. 

9.1 .6 STATUS-CBCH-QUERY Response/Confirm 



PARAMETER 


REFERENCE 


PRESENCE 


CBCH-Loading-List 

Failure-List 
Channel Indicator 


9.2.15 
9.2.14 
9.2.6 








This primitive will be sent by the BSC in response to the STATUS-CBCH-QUERY Request/Indication primitive. 

The CBCH-Loading-List, if present, may contain each cell which successfully performed the requested operation and 
for each of these cells the CBCH loading of this particular cell. (Note that for cells with DRX the load caused by the 
schedule messages will be included in the CBCH load). The CBCH-Loading-List will not be present if all cells indicated 
in the related STATUS-CBCH-QUERY Request/Indication failed the requested operation. 

The Failure-List, if present, may contain all cells for which the requested operation failed (e.g. because the cells CBCH 
is not available). The STATUS-CBCH-QUERY Response/Confirm will not contain the 

Failure-List parameter if none of the cells in the Cell-List of the related STATUS-CBCH-QUERY Request failed the 
requested operation. 
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9.1 .7 STATUS-MESSAGE-QUERY Request/Indication 



PARAMETER 


REFERENCE 


PRESENCE 


Message-Identifier 


9.2.1 


M 


Old-Serial-Number 


9.2.2 


M 


Cell-List 


9.2.5.1 


M 


Channel Indicator 


9.2.6 






This primitive is sent by the CBC to the BSC in order to obtain the current status of a CB-message for the cells 
referenced in the Cell-List parameter. This primitive is responded by the STATUS-MESSAGE-QUERY 
Response/Confirm or by a REJECT Response/Confirm. 

9.1 .8 STATUS-MESSAGE-QUERY Response/Confirm 



PARAMETER 


REFERENCE 


PRESENCE 


Message-Identifier 


9.2.1 


M 


Old-Serial-Number 


9.2.2 


M 


No-of-Broadcasts-Completed-List 


9.2.10 





Failure-List 


9.2.14 





Channel Indicator 


9.2.6 






This primitive will be sent by the BSC to the CBC in response to a STATUS-MESSAGE-QUERY Request/Indication 
primitive. 

The No-of-Broadcasts-Completed-List, if present, may contain each cell which successfully performed the requested 
operation and for each of these cells the number of times this CB message has been sent to this particular cell for 
broadcast (parameter Number-of-Broadcasts-Completed; this parameter is not included for the cell if the old message 
reference is not known to the BSC, and an entry is made in the failure list). The No-of-Broadcasts-Completed-List will 
not be present if all cells indicated in the related STATUS-MESSAGE-QUERY Request failed the requested operation. 

The Failure-List may contain all cells for which the requested operation failed (e.g. because the broadcast of the 
requested message was never requested before or because the cells CBCH is not available). The STATUS-MESSAGE- 
QUERY Response/Confirm will not contain the Failure-List parameter if none of the cells in the Cell-List of the related 
STATUS-MESSAGE-QUERY Request failed the requested operation. 



9.1.9 REJECT Response/Confirm 



PARAMETER 


REFERENCE 


PRESENCE 


Cause 


9.2.16 


M 


Diagnostic 


9.2.17 





Message-Identifier 


9.2.1 





Serial Number 


9.2.2 






This primitive is sent by the BSC to the CBC in response to any primitive which is not understood (e.g. invalid 
parameter or parameter value). 

9.1.10 RESTART-INDICATION Request/Indication 



PARAMETER 


REFERENCE 


PRESENCE 


Cell-List 
Recovery Indication 


9.2.5.2 
9.2.20 


M 




The RESTART-INDICATION Request is used by the BSC to indicate to the CBC a CB related restart situation in one 
or more of its cells (e.g. when an existing or a new cell becomes operational during normal BSC operation or when the 
BSC initialises). 

Any referenced cell are again in CB-operational state (have resumed CB operation). The parameter Recovery Indication, 
if present, indicates whether CB related data are lost for the cells referenced in the Cell-List and have to be re-loaded. If 
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the Recovery Indication parameter is absent, the CBC shall interpret it as the Recovery Indication with the value data 
lost. 

The CBC upon receiving a RESTART INDICATION indication, marks the cell as operational again. It will usually 
generate WRITE-REPLACE requests for this cell, according to the actual CB message loading at the moment of the 
restart. 

Note that a RESTART INDICATION indication may be triggered from the CBC by a RESET Request. This allows to 
recover from situations, where a PDU occasionally may be lost. 



9.1 .11 RESET Request/Indication 



PARAMETER 


REFERENCE 


PRESENCE 


Cell-List 


9.2.5.1 


M 



The RESET Request is used by the CBC to force one or more cells (BTSs) of one BSC into CB-idle state. 

The RESET Request may also be used by the CBC to ask for the CB operational state of cells earlier indicated to have 
failed (polling CB operational state). 

If a base station controller (BSC) receives a RESET Indication, the indicated cells enter idle state (same state as after 
"power on"). All CB related information concerning earlier CB messages in a referenced cell is lost. 

The BSC acknowledges the RESET Indication for each cell by an RESTART- or, if not adequate, by a FAILURE- 
INDICATION request. 

Of course, several responses may be combined using a cell list in the RESTART or FAILURE INDICATION. 

9.1.12 FAILURE-INDICATION Request/Indication 



PARAMETER 


REFERENCE 


PRESENCE 


Cell-List 


9.2.5.2 


M 



The FAILURE-INDICATION Request is used by the BSC to indicate to the CBC a CB related problem situation in one 
or more of its cells. 

Any referenced cell enters CB-not-operational state. The status of the CB messages is undefined until the Restart- 
Indication is sent. It remains in not-operational state until a RESTART-INDICATION request (see 9.1.10) indicates 
normal CB operation (again). 

The CBC upon receiving a FAILURE indication, marks this cell as failed. It will generally not generate further WRITE- 
REPLACE requests for this cell, up to the point, when the CBC is informed by a RESTART indication, that the cell has 
resumed CB operation. 

The BSC refuses further WRITE-REPLACE requests from the CBC with the cause "cell-broadcast-not-operational" 
when any referenced cell is in the CB-not-operational state. 

Note, that a Failure-Indication may be triggered by a RESET Request. This allows to recover from situations, where a 
PDU occasionally may be lost. 



9.1.13 SET-DRX Request/Indication 



PARAMETER 


REFERENCE 


PRESENCE 


Cell-List 


9.2.5.1 


M 


Schedule-Period 


9.2.12 





Reserved-Slots 


9.2.13 





Channel Indicator 


9.2.6 






The SET-DRX Request is used by the CBC to set DRX specific parameters i.e. the schedule period and the number of 
slots reserved for high priority messages, see GSM 04.12. At least one of the Schedule-Period or Reserved-Slots 
parameters must be present in the primitive. If this primitive is not supported, the BSC may use default values. 
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If a base station controller (BSC) receives a SET-DRX Indication, the new DRX parameters will be taken into account 
starting from the next schedule period in each cell, see GSM 04.12. 

If a BSC receives a SET-DRX Indication, the new DRX parameters will be applied for all cells that do not handle any 
broadcast message (null loading). 

9.1.14 SET-DRX- REPORT Response/Confirm 



PARAMETER 


REFERENCE 


PRESENCE 


Cell-List 

Failure-List 

Channel Indicator 


9.2.5.2 
9.2.14 
9.2.6 








This primitive will be sent by the BSC to the CBC in response to a SET-DRX Request/Indication primitive. 

The Failure-List will contain those cells which were present in the Request message and which failed the requested 
operation. 

If the new schedule period parameters are not acceptable on a cell due to the load of the cell, the cause "bss-capacity- 
exceeded" is used in the Failure-list. 

9.2 Parameters 

9.2.1 Message-Identifier 

identifies source/type of message. 

9.2.2 Old-Serial-Number 

This enables a particular existing message, from the source/type indicated by the message identifier, to be identified. 

9.2.3 New-Serial-Number 

This enables message change to be indicated since it is altered every time the message is changed. The serial number 
identifies a particular message, which may be several pages in length, from the source indicated by the message 
identifier. 

9.2.4 Number-of-Pages 

enables the number of pages in the message to be indicated. 

9.2.5 Cell-List 

The cell-list identifies a sequence of one or more cells to which the primitives apply. 

3The cells in the list are described as per section 3.2.2.17 of GSM 08.08 and can be identified by the CBC or BSC in 
LAC and CI format or CI format only. 

In addition (as described in GSM 08.08) it is possible for the CBC to refer to all cells in a LAC or in a complete BSC. 
If supplied, the Cell-List parameter must refer to at least one cell. 

Given the above differences between cell identification in the two directions, a cell list sent from the CBC to the BSC 
has a different structure compared to a cell list sent from the BSC to the CBC. The different cell lists are described in 
sections 9.2.5.1 and 9.2.5.2. 
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9.2.5.1 Cell-List sent from CBC to BSC 

The CBC to BSC Cell-List contains a length parameter identifying the number of cell-identifications present in the list, a 
Cell-Id-Discriminator, which is common for all cell-identifications in the list, and a sequence of cell-identifications. 

Description of list elements: 



PARAMETER 


PRESENCE 


Length 

Cell-Id-Discriminator 

Cell-Identification 


M 
M 
M 



The Cell-Id-Discriminator is described as per section 3.2.2.27 of GSM 08.08 and has one of the following formats: 

- LAC and CI; 

- CI only; 

all cells in the BSC belonging to a certain Location Area; 

- all cells in the BSC. 

The Cell-identification is repeated for each cell included in the list. The Cell-List must refer to at least one cell. 

9.2.5.2 Cell-List sent from BSC to CBC 

The BSC to CBC Cell-List contains a sequence of cell-identifiers as defined in 9.2. 11. The Cell-List must contain at 
least one cell-identifier as defined in 9.2. 11. 

9.2.6 Channel Indicator 

This parameter indicates the CB channel, which shall be used for broadcasting the data. 
basic channel; 

extended channel (supporting such a channel by the network or MSs is optional); 
If no channel indicator is present, it shall be interpreted as an indication to the basic channel. 

9.2.7 Category 

This indicates the category of the message: 

High Priority: to be broadcast at the earliest opportunity in the reserved slots of the current schedule period (i.e. until 
the emission of the next schedule message), then according to the associated repetition period in the next 
schedule periods, in non reserved slots. 

Background: to be broadcast in the slots left free by messages of category "High Priority" and "Normal", 
possibly shared with unscheduled schedule messages, see GSM 04.12. The repetition period defines the 
minimum broadcast requirement. 

Normal: to be broadcast according to the associated repetition period. 

If the category is omitted, the default category imphed is "Normal" message. 



9.2.8 Repetition-Period 



This indicates the period of time after which broadcast of the message should be repeated. The minimum period with 
which a message may be broadcast over the air interface is one 8x51 multiframe sequence which corresponds to a 
period of approximately 1.883 seconds. 
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The value of "Repetition-Period" shall be in the range 1 to 1024 where each unit will represent one 8x51 multiframe 
sequence. 

In the event of a conflict where the BSS has more than one message to send at the same time, the BSC shall decide the 
order of such messages as an implementation matter. 

9.2.9 No-of-Broadcasts-Requested 

This specifies the number of times the message is to be broadcast. The parameter may take any value up to 65535 (this 
maximum allows the message to be broadcast approximately every 1.883 seconds for more than 24 hours). If the 
parameter is set to then the message will be broadcast indefinitely (i.e. until the BSC receives an appropriate Kill- 
Message Request/Indication primitive). 

9.2. 1 No-of-Broadcasts-Completed-List 

This parameter is a list indicating the number of times that the message (i.e. all pages of the message) has been sent to 
each Cell in the Cell-List for broadcast over the air interface. 

The cells in the list are described as per section 3.2.2. 17 of GSM 08.08 and can be identified by LAC and CI or CI only. 

Description of list elements: 



PARAMETER 


PRESENCE 


Cell Identifier 
No-of-Broadcasts-completed 
No-of-Broadcasts-Compl-lnfo 


M 
M 




The information above is repeated for the number of cells in the list. 

To each cell in the list the information element No-of-Broadcasts-completed is associated. This information element is 
related to the particular referenced cell in the list and contains the number of times a CB message (i.e. all pages of a CB 
message) has been sent to this cell for broadcast. The No-of-Broadcasts-completed information element represents the 
number of full broadcasts made of a message, and that the message is being (or had been) broadcast. 

The optional No-of-Broadcasts-Compl-Info information element may be supplied to indicate to the CBC one of the 
following cases: 

overflow 

the count of the number of full broadcasts made of a message has overflowed, and that the message is being (or 
had been) broadcast. The actual number of broadcasts completed is greater than the value indicated in the No-of- 
Broadcasts-completed information element. 

unknown 

indicates that there is no information regarding the number of broadcasts completed in the BSC for the message 
with the old serial number. The value indicated in the No-of-Broadcasts-completed information element is 
undefined in this case. 

The No-of-Broadcasts-Completed-List must contain at least one cell. 

9.2.11 Cell-Identifier 

The cell-identifier consists of a cell-id-discriminator and cell-identification pair. 
Description of list elements: 



PARAMETER 


PRESENCE 


Cell-ld-Discriminator 
Cell-Identification 


M 
M 



The Cell-Id-Discriminator is described as per section 3.2.2. 17 of GSM 08.08 and has one of the following formats: 
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- LAC and CI, 

- CI only. 

The BSC can use the 'LAC and CI' format for a cell identifier in any response to the CBC. The BSC may also use the 
'CI only' format for a cell identifier when responding to a CBC primitive that had contained a cell with 'CI only' format 
for a cell identifier. 

9.2.12 Schedule-Period 

Indicates the DRX schedule period length, see GSM 04.12. 
The following values should be coded: 

- no DRX; 

length of the schedule period. 

If a schedule period length greater than 40 is used, the schedule message cannot be built entirely if more than 40 
messages have to be described in the period. Therefore, schedule period length shall be reduced to 40. 

9.2.13 Reserved-Slots 

Indicates the number of slots marked as "free slots reading advised" in the schedule message and considered as reserved 
in a DRX schedule period for incoming high priority messages, not scheduled in the current schedule period, see 

GSM 04.12. 

The spacing of the reserved slots is implementation dependent. 

Reserved slots shall receive a 40 value at maximum, taking into account the constraint for schedule period length. 

9.2.14 Failure-List 

This identifies the list of cells for which the BSC could not complete the request. The failure cause for each cell is 
indicated. The cells in the list are described as per section 3.2.2. 17 of GSM 08.08 and can be identified by LAC and CI 
or CI only. 

Description of list elements: 



PARAMETER 


PRESENCE 


Cell Identifier 

Cause 

Diagnostic 


M 
M 




The information above is repeated for the number of cells that failed. 

To each cell in the list the information elements Cause and, as an implementation option. Diagnostic are associated. 
These are related to the particular referenced cell in the list. 

The Failure-List must contain at least one cell. 

9.2.15 CBCH-Loading-List 

A list of the predicted short term load of each cell in the list expressed as a percentage. The calculation of this 
percentage is an implementation matter. The load should reflect the number of used slots, and schedule messages and 
reserved slots must be taken into account. The cells in the list are described as per section 3.2.2.17 of GSM 08.08 and 
can be identified by LAC and CI or CI only. 

Description of list elements: 
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PARAMETER 


PRESENCE 


Cell Identifier 
CBCH-Loading 


M 
M 



The information above is repeated for the number of cells in the list. 

To each cell in the list the information element CBCH-Loading is associated. This information element is related to the 
particular referenced cell in the list and contains the cells load. 

Note that for cells with DRX the load caused by the schedule messages will be included in the CBCH load. 

The CBCH-Loading-List must contain at least one cell. 

9.2.16 Cause 

Indicates reason why the BSC was not able to interpret or execute the received primitive. The causes are given in table 
1. 

Table 1 



Cause 


Reason 


Parameter-not-recognized 


Sent when the recipient (CBC or BSC) was unable to act 
upon the primitive received due to an unrecognized 
parameter. A primitive should not be rejected only because a 
parameter is not recognized as this would prevent 
extensions to the service 


parameter-value-invalid 


Sent when a failure occurred due to the value of a parameter 
being invalid, e.g. out of range, or in Write-Replace, the 
parameter "no of pages" does not equal the number of 
pages received 


valid-CBS-message-not- identified 


Sent when the BSC does not recognize the CBS message 
reference 


cell-identity-not-valid 


Sent when the BSC does not recognize a cell Identity 


unrecognized-primitive 


Sent when the BSC did not recognize the primitive at all 


missing-mandatory-element 


Sent when a mandatory element is missing from the primitive 


bss-capacity-exceeded 


Sent when a write-replace fails because the BSC cannot 
meet the requested repetition period or when the set-drx 
parameters cannot be applied because of the cell loading 


cell-memory-exceeded 


Sent when the local cell memory has been exceeded 


bss-memory-exceeded 


Sent when the BSS is unable to store a message as the BSS 
memory has been exceeded 


cell-broadcast-not-supported 


Sent when the CBCH is not configured for a cell 


cell-broadcast-not-operational 


Sent when the CBCH is not available because of error 
conditions or due to maintenance activities 


incompatible-DRX-parameter 


Sent when the DRX parameter(s) cannot be applied. 


Extended-channel-not-supported 


Sent when a write-replace fails because the extended 
channel is not configured for a cell 


message-reference already-used 


Sent when the recipient (BSC) was unable to act upon the 
write_replace received due to a previous write_replace 
received with the same message reference. 


unspecified-error 


Sent when none of the above cause values apply 



9.2.17 Diagnostic 

Provides additional information associated with Cause parameter and may contain parameter which could not be 
interpreted/executed. 

9.2. 1 8 Data Coding Scineme 

Identifies alphabet or coding employed for the message characters. This field is defined in GSM 03.38 [3]. 
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9.2.19 CBS-Message-Information-Page n 

This carries 82 octets of CBS information. 

9.2.20 CBS-Message-Information-Length n 

Gives the number of octets of the CBS-Message-Information-Page n containing cell broadcast information. The 
remaining octets of the CBS-Message-Information-Page n only contain padding information. 

9.2.21 Recovery-Indication 

Indicates whether the CBS related data was lost or is still available. 
The following values should be coded: 

Data-available; 

Data-lost. 

9.3 Message Format on BTS-MS Interface 

The messages which are transmitted by the BTS for the MS include the SMSCB message (information for the user) and 
Schedule Message (schedule of SMSCB messages). 

The Schedule Message is broadcast to support SMSCB DRX mode for Mobile Stations. The Schedule Message is 
helpful in minimizing battery usage for Cell Broadcast in the Mobile Station, because it allows the MS to ignore 
transmissions of messages the customer is not interested in. Use and formatting of the Schedule Message is described in 
GSM 04.12. 

The use and the formatting of the SMSCB messages, which contain information for the MS user, is described in this 
section. 

9.3.1 General Description 

Each CBS page sent to the MS by the BTS is a fixed block of 88 octets as coded in GSM 04.12. This is sent on the 
channel allocated as CBCH by GSM 05.02. The 88 octets of CBS information consist of a 6 octet header and 82 user 
octets. 

9.3.2 Message Content 

Octet No 1-2 Serial Number 

3-4 Message Identifier 

5 Data Coding Scheme 

6 Page Parameter 

7-88 Content of Message 

These octets are transmitted in order, starting with octet 1. The bits within these octets are numbered to 7; bit is the 
low order bit and is transmitted first. 

The fields are used as follows: 

(i) Serial Number is a 16 bit integer which identifies a particular message (which may be one to 15 pages in length) 
from the source and type indicated by the Message Identifier and is altered every time the message with a given 
Message Identifier is changed. 

The two octets of the serial number field are divided into a 2-bit Geographical Scope indicator, a 10-bit Message 
Code and a 4-bit Update Number in the following structure : 
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Octet 1 



Octet 2 



7 


6 


5 


4 


3 


2 


1 







7 


6 


5 


4 


3 


2 


1 






<>K 



GS 



Message Code 



>K 



> 



Update Number 



The most significant bit of the Message Code is octet 1 bit 5 and the least significant bit of the Message Code is 
octet 2 bit 4. The most significant bit of the update number is octet 2 bit 3. 

The Message Code will differentiate between messages from the same source and type (with the same Message 
Identifier). Message Codes are for allocation by PLMN operators. 

The Message Code identifies different message themes. So, for example, let the value for the message identifier 
be "Automotive Association"= source), "Traffic Reports" = type). Then "Crash on Al J5" could be one value for 
the message code "Cow on A32 J4" could be another "Slow vehicle on M3 J3" yet another. 

The Geographical Scope (GS) indicates the geographical area over which the Message Code is unique, and the 
display mode. The message is not necessarily broadcast by all cells within the geographical area. When two 
messages are received with identical Serial Numbers/Message Identifiers in two different cells, the Geographical 
Scope may be used to determine if the messages are indeed identical. 

In particular, the Geographical Scope tells the mobile if the message is only cell wide (which means that any 
message if received in the next cell is regarded as "new"), or PLMN wide (which means that the Message Code 
and/or Update Number must change in the next cell for the message to be "new"), or location area wide (which 
means that a message with the same Message Code and Update Number may or may not be "new" in the next cell 
according to whether the next cell is in the same location area as the current cell). 

The display mode indicates whether the message is supposed to be on the display all the time ("immediate") or 
only when the user wants to see it ("normal"). 

The coding of this field that indicates the scope of the message is: 

CODE DISPLAY MODE GEOGRAPHICAL SCOPE 

00 Immediate Cell wide 



01 



Normal 



PLMN wide 



10 



Normal 



Location Area wide 



1 1 Normal Cell wide 

Immediate = default direct display; 

Normal = default display under user interaction. 

NOTE 1 : These display modes are indicative of intended use, without indicating a mandatory requirement or 
constraining the detailed implementation by mobile manufacturers. The user may be able to select 
activation of these different modes. 

NOTE 2: Code 00 is intended for use by the network operators for base station IDs. 

The Update Number indicates a change of the message content of the same message, i.e. the message with the 
same Message Identifier, Geographical Scope, and Message Code. 

In other words, the Update Number will differentiate between older and newer versions of the same message, 
within the indicated geographical area. A new message may have Update Number 0000; however this number 
will increment by 1 for each update. Any Update Number eight or less higher (modulo 16) than the last received 
Update Number will be considered more recent, and shall be treated as a new message, provided the mobile has 
not been switched off. 

(ii) Message Identifier identifies the source and type of message. For example "Automotive Association" (= source), 
" Traffic Reports" (= type) could be one value. A number of messages may originate from the same source and/or 
be of the same type. These will be distinguished by Serial Number. The Message Identifier is coded in binary. 
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The ME shall attempt to receive the CBS messages whose Message Identifiers are in the "search list". This 
"search list" shall contain the Message Identifiers stored in the EFcBMb EFcbmid and EFcbmir files on the SIM 
(see GSM 11.11) and any Message Identifiers stored in the ME in a "list of CBS messages to be received". If an 
ME has restricted capabilities with respect to the number of Message Identifiers it can search for, then the 
Message Identifiers stored in the SIM shall take priority over any stored in the ME. 

The use/application of the Message Identifiers is as follows: 

0000 - 03E7 (hex) to be allocated by PLMN operator associations. If a Message Identifier from this range 
is in the "search list", then the ME shall attempt to receive this message. 

03E8 - OFFF (hex) intended for standardization in future versions of GSM 03.41. These values shall 

not be transmitted by networks that are compliant to this version of GSM 03.41. If a Message 

Identifier from this range is in the "search list", then the ME shall attempt to receive this message. 

1000 - lOFF (hex) Networks shall only use Message Identifiers from this range for Cell Broadcast Data 

Download to the SIM (see GSM 1 1 . 14). If a message Identifier from this range is in the "search list", 

then the ME shall attempt to receive this message. 

NOTE: This version of GSM 03.41 does not prohibit networks from using Message identifiers in the range 0000 - 
03E7 (hex) for Cell Broadcast Data Download to the SIM. 

1 100 - FFFE (hex) intended for standardization in future versions of GSM 03.41. These values shall 

not be transmitted by networks that are compliant to this version of GSM 03.41. If a Message 

Identifier from this range is in the "search list", then the ME shall attempt to receive this message. 

FFFF (hex) Reserved, and should not be used for new services, as this value is used on the SIM to 

indicate that no Message Identifier is stored in those two octets of the SIM. If this Message Identifier 

is in the "search list", then the ME shall attempt to receive this message. 

In the above list, octet 3 of the Message Identifier is shown first, followed by octet 4. Thus "1234" (hex) 
represents octet 3 = 0001 0010 and octet 4 = 001 1 0100. 

NOTE 3: Optionally, the user can select the language(s) required by using an MMI, to determine whether a 
particular message should be read and displayed. 

Generally, the MMI for entering these codes in the ME is left to the manufacturers' discretion, however the 1000 
lowest codes shall be enterable by their decimal representation i.e: 

Octet 3 Octet 4 

0000 0000 0000 0000 (decimal '000') 

0000 0000 0000 0001 (decimal'OOl') 

0000 0000 0000 0010 (decimal '002') 

0000 0000 0000 001 1 (decimal '003') 



0000 00 1 1 1110 0111 (decimal '999') 

(iii) Data Coding Scheme indicates the intended handling of the message at the MS, the alphabet/coding, and the 
language (when applicable). This is defined in GSM 03.38 [3]. 

When the SIM indicates one or more language preferences, the ME shall, by default, use the language(s) stored 
in the SIM (in the EFlp file) to set any language filter mechanisms provided by the ME. 

(iv) The page parameter is coded as two 4-bit fields. The first field (bits 0-3) indicates the binary value of the total 
number of pages in the message and the second field (bits 4-7) indicates binary the page number within that 
sequence. The coding starts at 0001, with 0000 reserved. If a mobile receives the code 0000 in either the first 
field or the second field then it shall treat the message exactly the same as a message with page parameter 0001 
0001 (i.e. a single page message). 
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9.4 CBS Compression 

Not yet specified 

10 SMSCB Index 

An index structure is defined in this section. Index can be used by the operator to inform the end user about the type of 
SMSCB services available. Index has the structure of a tree. It can thus have sub parts which are called subindexes. A 
subindex can be embedded in the same index message as its parent ("embedded subindex") or it can physically be in a 
separate index message ("child subindex"). Every index message has a unique message identifier. They are always of the 
same type. Message Code 1010101010b shall be used to indicate this type. The root of the index structure shall be the 
index message with message identifier 0. Other index messages are linked to the root index with links. Definition of 
their message identifiers is left to the operator. 

A format ("enhanced format") for the index messages is described in this section. If this enhanced format is used in the 
index message the ms can present the index messages in its preferred format. 

Available SMSCB services are introduced in the index. This means that their message identifier and name are stated. 
Enhanced format includes a mechanism for separating a normal service introduction from embedded subindex 
introduction and child subindex introduction. The introduction of an embedded subindex specifies the "subindex-id" 
used for identifying services that belong to this subindex. Embedded subindexes can have subindexes embedded in them 
etc. If these "second level embedded subindexes" are introduced their subindex-id shall begin with the subindex-id of 
their parent. Same principle applies for subindexes in third, fourth etc. level. An example of an index structure is given 
in figure 4. 

Enhanced format includes a mechanism which allows the terminals to identify that the format of the index message is 
enhanced. The index-id -field and the above mentioned Message Code (1010101010b) constitute this mechanism: 

message-format = index-id index-element-introH- 

index-id = "EI" version crlf 

version = number-n 

number = "1" I "2" I "3" I "4" I "5" I "6" I "7" I "8" I "9" I "0" 

index-element-intro = subindex-intro I service-intro 

subindex-intro = subindex-id " " subindex-name crlf 

subindex-id = subindex-character-n 

subindex-character = "a" I "b" I ... I "z" I "A" I "B" I ... I "Z" 

subindex-name = name-character-n 

name-character = <gsm03.38character excluding <CR> and <LF> > 

crlf = <CR><LF> 

service-intro = subindex-id message-id delimiter service-name crlf. 

message-id = number-n 

delimiter = "." I " " 

service-name = name-character-n 

Current version used is 1 . 

The use of "." as delimiter means that this service is a child subindex of the index structure. 

Delimiter " " is used in all other cases. 
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Subindex-id shall not be used if the service introduced is in the first level of the index. Subindex-id:s are used in 
alphabetical order within an index message. They can be re-used in a child subindex. 



Index: 

(Msgld=0, Message Code 



1010101010b) 



EM 

20 Hospitals 

34 Taxis 

a News 

a201 Int News 

a202 Nat News 

a203 Local News 

b Sports 

b301 Football News 

b302 Hockey Results 

b303 Basketball 

c Finance 

c401 Finance News 

ca Quotes NYSE 

ca412 NYSE industrial 

ca413 NYSE electronics 

ca414 NYSE blue 

c420. Quotes Tokyo 

d Weather 

d501 Local Weather 

d502 National Weather 

d503 Weather in Europe 

d504 Weather in the World 

900. Buy and Sell 



420 Quotes Tokyo: 

(Msgid = 420, Message Code : 



Ell 




421 


Tokyo Industrial 


422 


Tokyo Finance 


423 Tokyo Blue 



1010101010b) 



900 Buy and Sell: 


(MsgId = 900, Message Code = 


Ell 


901 Cars 


902 Bikes 


903 Boats 


a Home Electronics 


a911 Computers 


a912 Televisions 


a913 Radios 


920 Baby Clothes 


930 Magazines 


940 Books 



1010101010b) 



Figure 4 
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Annex A (informative): 

Protocols for interconnecting CBC and BSC 

No mandatory protocol between the Cell Broadcast Centre (CBC) and the Base Station Controller (BSC) is specified by 
GSM; this is a matter of agreement between CBC and PLMN operators. 

Some example protocols are provided in GSM 03.49 to assist CBC and PLMN operators. These are based on the 
following principles, which CBC and PLMN operators are recommended to follow even if they choose not to use one of 
the examples given in GSM 03.49. 

The protocol(s) between CBC and BSC should: 

a) provide the service defined for the CBC-BSC interface (see section 9); 

b) be based on protocols normally used for communication between switching and/or computer equipment; 

c) permit open interconnection - preferably using the OSI stack or equivalent (e.g. CCITT Number 7 Stack). 
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Annex B (informative): 
Change Request History 



SMG 


SPEC CR PHA VERS NEW_VE SUBJECT 


s25 


03.41 


A053 R97 5.8.0 6.0.0 


SMSCB Message serial number update 


S26 


03.41 


A055 ,R97 ,6.0.0 ,6.1.0 

1 1 1 


Alignment of 03.41 with 11.11 
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